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The  thesis  describes  a  prototype  version  of  a  flexible 
message  processor  designed  for  computer  communications 
network  applications.  This  message  processor  is  micro¬ 
computer  based  and  is  called  a  Universal  Network  Interface 
Device.  The  thesis  describes  the  operational  features  and 
construction  details  of  the  three  cards,  which  were  devel¬ 
oped  in  the  construction  of  the  prototype  device.  These 
three  cards  are  used  with  two  microcomputer  boards  and  a 
memory  board  to  provide  the  capability  to  interface  local 
users  to  a  computer  communications  network.  The  device 
also  provides  the  capability  to  act  as  the  node  connecting 
two  networks  operating  under  dissimilar  protocols. 
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PROTOTYPE  UNIVERSAL  NETWORK  INTERFACE  DEVICE 


I •  Introduction 

The  purpose  of  this  investigation  was  to  perform  an 
implementation  of  a  microcomputer  based  message  processor 
with  the  inherent  flexibility  which  would  allow  it  to  be 
used  in  different  types  of  data  communications  network 
applications.  Using  a  preliminary  design,  the  message 
processor  was  implemented  using  a  modular  approach.  Since 
the  device  is  microcomputer  based,  the  resident  software 
can  be  modified  to  configure  the  device  for  the  required 
type  of  message  processor  of  a  given  application. 

The  remaining  sections  of  this  chapter  will  address 
background  information  relative  to  this  effort,  the  basic 
design  of  this  message  processor  which  is  called  a  Universal 
Network  Interface  Device  (UNID) ,  the  problem  statement 
and  approach,  and  an  overview  of  the  subjects  covered  in 
this  report. 

BasKaround 

The  1842  Electronics  Engineering  Group  (EEG)  completed 
a  report  on  31  OCT  77  entitled  An  Engineering  Assessment 
Toward  Economic,  Feasible  and  Responsive  Base-Level  Communi¬ 
cations  Through  the  1980 's  (Ref  1) .  This  report  was  written 
to  provide  an  engineering  input  to  the  Air  Force  Communica¬ 
tions  Service  (AFCS)  planning  process  for  meeting  base-level 
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telecommunications  needs.  The  report  reviews  current  and 
planned  base  telecommuncations  requirements  and  capabili¬ 
ties.  It  also  provides  a  technological  forecast  and  the 
possible  effect  of  technology  on  user  requirements.  The 
last  part  of  the  report  describes  the  composite  scenario 
of  "typical"  base-level  telecommunications  requirements 
and  capabilities  through  1990.  The  last  two  parts  of  the 
1842  EEG  report  introduced  the  concept  of  a  multi-ring 
network  as  being  the  prime  candidate  for  a  base-level 
telecommunications  network.  This  multi-ring  network 
offered  particular  advantages  in  terms  of  cost,  evolutionary 
implementation  and  flexibility.  A  key  to  the  multi-ring 
concept  was  the  development  of  five  different  devices  which 
could  interface  the  multiple  rings  together. 

Rome  Air  Development  Center  (RADC)  was  tasked  with 
addressing  the  problem  of  the  interface  devices.  It  was 
recognized  that  the  various  interface  devices  proposed  had 
similar  features  and  were  required  to  perform  similar 
functions.  Thus  it  appeared  reasonable  that  a  single, 
albeit  flexible  interface  device  could  be  developed  which 
could  meet  the  separate  requirements  of  each  of  the  five 
proposed  interface  devices  of  the  multi-ring  concept.  This 
idea  was  incorporated  into  a  postdoctoral  study  program, 
and  later  became  the  basis  of  a  preliminary  research  inves¬ 
tigation  (Ref  12).  The  report  of  the  investigation,  entitled 
Preliminary  Design  of  a  Universal  Network  Interface  Device, 


was  the  first  phase  of  an  effort  to  develop  the  required 


message  processor.  The  investigation  involved  definition  of 
the  functional  requirements  of  the  device,  translation  of 
these  requirements  into  an  overall  system  design,  design 
of  the  hardware  of  the  device,  and  the  development  of  the 
software  routines  to  verify  the  correct  operation  of  the 
device.  The  referenced  document  was  the  principal  source 
of  information  for  the  actual  implementation.  The  overall 
design  of  the  device  as  proposed  was  excellent  and  it  was 
this  general  design  which  was  employed  in  implementing  the 
device . 

Basic  Design  Approach 

The  basic  design  of  the  device  involved  two  Z-80 
Microcomputer  Boards  which  shared  a  common  block  of  memory. 
Each  of  the  microcomputer  boards  will  perform  specific 
tasks  within  the  framework  of  the  device.  To  meet  the 
"universal"  qualification  the  UNID  would  have  to  interface 
to  users  directly  or  through  Modems.  Also,  the  device 
must  be  able  to  interface  with  a  data  communications  network. 
To  be  able  to  perform  these  two  types  of  interfacing  two 
special  cards  were  designed,  the  Local  Card  and  the  Network 
Card. 

The  design  as  specified  in  the  previous  effort  was 
chosen  to  provide  modularity  of  the  hardware  so  that  the 
device  could  be  increased  in  capability  by  the  addition  of 
one  or  more  Local  or  Network  Cards.  The  Local  Card  pro¬ 
vided  the  means  to  interface  up  to  four  RS-232C  users  with 


the  device.  Through  the  addition  of  more  Local  Cards  addi¬ 
tional  users  could  be  serviced  by  the  device.  The  Network 
Card  was  designed  around  the  Z-80A  SIO,  since  the  SIO  was 
part  of  the  Z-80A  family  of  chips  and  the  SIO  provided 
significant  capability  for  interfacing  with  different 
network  protocols.  Two  Network  Cards  would  be  used  in  the 
device  if  the  UNID  was  to  act  as  an  inter-ring  interface 
mode . 

As  previously  mentioned,  Z-80  Microcomputer  Boards 
(MCB)  were  chosen  as  the  processor  boards  in  this  design. 

The  preliminary  design  called  for  Z-80A  processor  boards 
due  to  the  speed  of  the  Z-80A,  its  vectored  interrupt  capa¬ 
bility  and  its  sophisticated  instruction  set.  However, 
when  the  hardware  was  procured  no  commercially  available 
Z-80A  MCB's  existed;  therefore,  Z-80  MCB ' s  were  purchased 
and  were  used  in  the  prototype  implementation  in  this  effort. 

The  basic  design  did  call  for  a  block  of  memory  to  be 
shared  to  allow  communications  between  the  two  microcom¬ 
puters  used  in  the  device.  To  meet  this  design  feature, 
the  Dual  Processor  Card  was  designed.  This  Card  acted  as 
a  memory  arbitrator  between  the  two  microcomputers  when 
simultaneous  accesses  to  the  shared  memory  block  were 
attempted.  The  Dual  Processor  Card  also  arbitrated  the 
refresh  signals  developed  by  the  two  processors,  so  that 
the  shared  memory  would  be  correctly  refreshed  and  memory 


accesses  would  not  interfere. 


Thus  the  overall  design  of  the  device  would  be  des¬ 
cribed  as  a  dual  processor  device  with  one  shared  memory 


partition  to  allow  processor  communication.  One  processor 
would  handle  the  data  flow  to  and  from  local  users  through 
the  use  of  one  or  more  Local  Cards.  The  second  processor 
would  process  the  network  traffic  through  use  of  the  Net¬ 
work  Card  and  the  processor's  capabilities. 

Problem  Statement  and  Approach 

The  objective  of  this  investigation  was  the  implemen¬ 
tation  of  a  prototype  Universal  Network  Interface  Device. 
This  objective  included  both  the  hardware  and  software 
required  for  device  operation.  The  hardware  implementation 
is  essentially  complete;  however,  the  development  of  soft¬ 
ware  was  limited  to  simple  routines  used  in  testing  various 
parts  of  the  device. 

The  approach  taken  to  meet  the  stated  objective  in¬ 
volved  three  phases.  The  first  phase  of  the  investigation 
was  a  study  of  previous  research  and  of  material  relating 
to  final  uses  of  the  device.  The  second  phase  involved 
testing  of  the  individual  cards  after  they  had  been  con¬ 
structed  in  breadboard  form.  The  last  phase  of  this  inves¬ 
tigation  dealt  with  the  construction  of  the  cards  and  the 
associated  integration  of  the  prototype  device. 

Overview 

Much  effort  was  expended  during  certain  portions  of 
this  investigation  in  order  to  attempt  to  understand 


previous  work  and  to  verify  the  operation  of  boards  imple¬ 
mented.  Discussion  related  to  these  areas  is  limited 
because  it  contributes  little  to  the  understanding  of  the 
effort.  Instead  the  discussion  is  centered  on  what  was 
accomplished  on  the  prototype  UNID  and  the  various  aspects 
of  the  device. 

Therefore  the  subsequent  chapters  are  intended  to 
provide  a  thorough  description  of  the  prototype  UNID. 

Chapter  II  provides  descriptions  of  the  design  and  opera¬ 
tion  of  the  Dual  Processor  Card.  Chapters  III  and  IV 
likewise  address  the  Local  Card  and  the  Network  Card, 
respectively.  Chapter  V  covers  the  entire  device  and  the 
specific  features  involved  in  the  design.  The  sixth  and 
final  chapter  provides  a  summary  of  the  thesis  and  recom¬ 
mendations  for  follow-on  effort.  The  appendices  which  are 
referenced  to  are  included  in  a  second  report,  since  the 
drawings  are  on  oversized  paper  which  could  not  be  included 
in  this  report. 


II .  Dual  Processor  Card 

The  key  to  the  overall  design  was  the  use  of  two 
microcomputers  as  the  processors  within  the  device.  In 
order  for  data  to  be  effeciently  transferred  between  the 
two  microcomputers  it  was  decided  that  a  particular  block 
of  memory  should  be  shared  by  the  two  processors.  This 
shared  block  of  memory  would  contain  tables  defining  the 
status  and  characteristics  of  messages  being  transferred 
through  the  device.  Also  when  a  message  is  being  trans¬ 
ferred  through  the  device,  the  message  would  be  stored  in 
the  shared  memory  by  one  processor  which  would  allow  the 
second  processor  access  to  the  message. 

The  circuitry  required  to  manage  the  requests  to  the 
block  of  shared  memory  is  called  the  Dual  Processor  Card. 
This  card  uses  the  control  signals  from  each  microcomputer 
to  arbitrate  accesses  to  a  shared  16K  byte  block  of  dynamic 
Random  Access  Memory  (RAM) .  This  16K  of  RAM  is  contained 
on  a  separate  board  which  was  purchased  from  Zilog  along 
with  the  two  Z-80  MCB's. 

This  chapter  will  describe  the  detailed  operation  of 
the  Dual  Processor  Card.  This  description  is  provided, 
so  that,  in  follow-on  efforts  a  minimal  amount  of  time 
is  spent  in  understanding  the  current  design.  The  circuitry 
on  the  card  can  be  apportioned  rather  easily  into  the  arbi¬ 
tration  logic  and  the  bus  and  control  signal  logic.  There¬ 
fore,  this  chapter  will  first  examine  the  arbitration  logic 
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and  then  will  address  the  bus  and  control  signal  logic. 


Arbitration  Logic 

The  arbitration  logic  is  duplicated,  in  that,  the 
signals  from  each  processor  are  processed  identically  to 
develop  the  proper  signals  at  the  proper  time  to  perform 
memory  accesses  and  memory  refresh.  The  two  processors 
were  arbitrarily  designated  X  and  Y,  where  the  X  processor 
would  process  the  local  traffic  while  the  Y  processor  would 
handle  the  network  traffic.  Thus,  in  the  descriptions  that 
follow,  the  terms  XA15,  YM1,  and  MREQ  refer  to  the  high- 
order  address  line  of  the  X  processor,  the  Ml  signal  of 
the  Y  processor,  and  the  MREQ  (memory  request)  signal  which 
goes  out  to  the  block  of  shared  memory,  respectively. 

Timing  diagrams,  with  explanations,  for  instruction 
op  code  fetch  and  for  memory  read  or  write  cycles  are  pro¬ 
vided  in  Figure  2-1.  These  diagrams  are  taken  from  the 
Zilog  Z80-CPU/Z80A-CPU  Product  Specification  (Ref  17)  and 
illustrate  the  relative  timing  of  the  signals  processed  by 
the  arbitration  logic.  It  should  be  noted  that  the  clocks 
of  the  microcomputers  are  180°  out  of  phase  with  each 
other  to  insure  that  memory  accesses  and  memory  refreshes 
do  not  occur  simultaneously. 

The  arbitration  logic  for  the  X  processor  is  shown 
in  Figure  2-2.  The  Y  processor  uses  an  identical  circuit; 
the  only  difference,  is  that  the  X  signals  are  replaced 
with  the  corresponding  Y  signals  and  vice  versa.  The 
XA14  is  inverted  and  AND'ed  with  the  XRFSH  and  XA15  to 
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Fig.  2-2.  Arbitration  Logic 


generate  the  XREQ  signal.  The  XREQ  signal  is  inverted  and 
OR'd  with  the  XMREQ  to  generate  the  XSEL  signal.  When 
XSEL  is  true,  the  X  processor  is  attempting  a  memory  ac¬ 
cess  into  the  shared  block  of  memory  which  resides  in 

address  space  8000  to  BFFF  .  If  XEN  is  high,  then  the 

H  H 

■  ■- —  i 

XSEL  is  generated  and  is  later  used  in  developing  the  bus 
control  signals  and  the  control  signals  to  the  shared 
memory.  XEN  will  be  high  as  long  as  no  memory  access  or 
memory  refresh  has  been  initiated  by  the  Y  processor. 

The  arbitration  of  the  refresh  signals  is  more 
complicated.  The  XRFSH  is  always  preceded  by  an  XM1  signal 
as  indicated  in  Figure  2-1.  The  XMl  signal  is  delayed  go¬ 
ing  through  two  74L0 4  gates,  yet  causes  flip-flop  1  to  be 
preset  to  "1",  which  deactivates  the  preset  input  of  flip- 
flop  2.  The  D  input  of  flip-flop  2  is  a  "0"  unless  the 
Y  processor  has  initiated  a  memory  access  or  memory  re¬ 
fresh.  The  XRFSH  signal  is  inverted  and  then  delayed 
through  two  74L04  gates.  This  delay  is  necessary  since  the 
MREQ  signal  occurs  after  the  trailing  edge  of  a  clock 
pulse.  On  the  other  hand  the  RFSH  signal  occurs  after 
the  leading  edge  of  a  clock  pulse.  With  the  processors 
operating  180°  out  of  phase  and  with  no  delay  on  the  RFSH 
signals,  XSEL  and  YRFSH  were  occurring  at  the  same  time. 
Therefore  the  delay  was  implemented  on  the  refresh  signal. 

The  delayed  XRFSH  signal  would  cause  the  Q  output  of 
flip-flop  2  to  go  low  (conditioned  on  no  memory  access  or 
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memory  refresh  by  the  Y  processor)  providing  the  XRFSH 

-  I  .  . 

signal.  XRFSH  remained  low  until  XMREQ  and  XRFSH  go 
high  which  provides  the  leading  edge  to  clock  flip-flop 
1  causing  a  "0"  at  the  Q  output  presetting  flip-flop  2 

l 

back  to  a  "1".  Meanwhile  XRFSH  signal  is  used  to  enable 
the  74126  and  allow  the  generation  of  the  XRFMQ  (X  refresh 
memory  request)  signal. 

Finally,  the  YEN  signal  is  developed  by  AND'ing 
the  XSEl'  and  XRFSH '  together.  As  long  as  XSEL '  and  XRFSH ' 
were  high  the  Y  processor  could  make  a  memory  access . 

The  arbitration  logic  for  the  Y  processor  is  a  perfect 
mirror  image  of  the  logic  described  above  relating  to  the 
X  processor  arbitration  logic.  A  complete  schematic  of 
the  Dual  Processor  Card  is  provided  in  Appendix  A  and  the 
dual  nature  of  the  arbitrator  is  reflected  in  that  sche¬ 
matic. 

Bus  and  Control  Signal  Logic 

The  remainder  of  the  logic  on  the  Dual  Processor  Card 
is  involved  in  the  generation  of  signals  to  control  the 
data  and  address  buses,  to  control  read  and  write  opera¬ 
tions  on  the  shared  memory  and  to  place  either  processor 
into  a  WAIT  condition  pending  the  availability  of  the 
shared  memory  for  a  memory  access . 

_ _ I 

The  address  bus  control  signals  are  STROBE,  STROBE  , 

|  _  _ 

YEN,  and  XSEL  .  Figure  2-3  shows  how  the  STROBE  and  STROBE 

are  generated  from  other  signals  produced  by  the  arbitration 
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logic.  These  signals  are  used  to  control  the  address  bus 
and  the  RD  and  WR  signals.  Figure  2-4  shows  how  the  signals 
are  applied  to  the  74S157fe  to  control  the  address  buses  and 
the  RD  and  WR  signals.  The  YEN  signal  can  be  defined  as 
a  SELECTX  signal  since  it  indicates  an  X  processor  memory 
operation  when  it  is  low.  Thus  the  SELECTX  signal  is  used 
on  the  low  ordi->r  byte  of  the  address  bus  selectors,  because 
data  is  transferred  on  A7-A0  during  a  memory  refresh  opera- 

- '  -  --  i 

tion.  On  the  other  hand,  the  XSEL  signal  is  used  on  the 
high-order  byte  of  the  address  bus  selectors  and  on  the 
RD  and  WR  signal  selector.  The  STROBE  signal  is  used  on 

■  .  -  ...  -  l 

the  low-order  byte  address  bus  selectors  and  STROBE  signal 
is  used  on  the  high-order  byte  and  on  the  RD  and  WR  selectors 
for  the  same  reasons. 

_ ( 

The  data  bus  is  controlled  by  means  of  the  XSEL  , 

(  YSEL ’ ,  XWR,  YWR,  XRD  and  YRD  signals.  Figure  2-5  shows  how 


13 


-74S157 ' 


Fig.  2-4.  Address  Bus  and  RD  and  WR  Signal  Control 


Fig.  2-5.  Data  Bus  Control  Signals 


these  signals  are  used  to  control  the  data  buses.  Basically 
the  XSEL  and  YSEL  signals  act  as  enable  signals  on  the 
X  and  Y  data  bus  drives,  respectively.  Meanwhile,  the 
XWR,  YWR,  XRD  and  YRD  signals  are  used  to  control  the  direc¬ 
tion  in  which  the  bus  is  driven. 

The  control  signals  to  the  shared  memory  and  back  to 
the  two  processors  are  WR,  RD,  MREQ,  RFSH,  XWAIT  and  YWAIT. 
The  WR  and  RD  signals  are  managed  by  the  STROBE  and  the 
XSEL  signals  as  indicated  during  the  discussion  relating 
to  the  control  of  the  address  bus.  Figure  2-6  shows  how 
various  arbitration  logic  signals  are  combined  to  produce 
MREQ,  RFSH,  XWAIT  and  YWAIT.  MREQ  is  developed  by  delaying 
the  logical  AND  of  XSEl' ,  YSEl' ,  XRFMQ  and  YRFMQ .  The  de¬ 
lay  is  necessary  to  insure  that  the  addresses  going  to  the 
shared  memory  have  had  time  to  stabilize  before  being  gated 
by  the  MREQ  signal.  The  RFSH  signal  is  developed  from  the 
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logical  AND  of  the  XRFSH  signal  and  the  YRFSH  signal. 

XWAIT  is  generated  when  XSEL  goes  low  at  a  time  in  which 
the  Y  processor  is  performing  a  memory  operation  (XEN  is 
low) .  Conversely  YWAIT  occurs  when  YSEL  goes  low  during 
a  X  processor  memory  operation  (YEN  is  low) . 

This  completes  the  discussion  of  the  signal  flow  in 
the  Dual  Processor  Card.  It  should  be  evident  from  the 
discussion  that  it  is  possible  to  lose  refresh  cycles  in 
the  implementation  of  the  arbitrator.  Preliminary  analysis 
indicates  that  the  loss  of  a  given  refresh  cycle  would  not 


cause  the  loss  of  any  data.  In  a  worst  case  analysis; 
however,  it  was  found  that  128  refresh  cycles  will  occur 
at  least  every  820  usee,  if  the  processor  is  decoding  and 
processing  single  op  code  16-bit  loads  (for  example  LD  HL, 
(nn) ) .  This  instruction  requires  16  clock  cycles  for  de¬ 
coding  and  execution  (6.4  psec  for  a  2.5  MHz  execution 
time).  Thus,  in  this  case  there  would  be  at  least  two 
more  chances  to  perform  the  refresh  before  the  2  msec 
refresh  time  specification  was  surpassed.  It  is  unlikely 
that  this  would  occur.  Also  it  should  be  noted  that  there 
is  a  second  processor  providing  refresh  signals  and  that 
the  typical  time  between  individual  refresh  cycles  is 
about  7  clock  cycles  or  2.8  psec.  For  these  types  of 
instructions,  to  complete  128  refresh  cycles  would  require 
around  360  pisec  which  indicates  over  5  complete  refresh 
cycles  every  2  msec.  Therefore,  the  loss  of  some  refresh 
cycles  should  not  cause  any  loss  of  data. 

As  stated  before,  a  complete  schematic  is  included 
in  Appendix  A.  The  Dual  Processor  Card  was  implemented 
on  a  standard  Z-80  Wire  Warp  Board  which  is  the  same 
size  as  the  other  Z-80  boards.  These  wire  wrap  boards 
include  space  for  sixty  16-pin  devices  along  with  several 
24,  28,  or  40-pin  devices.  In  the  schematics  the  pin 
numbers  correspond  to  the  pin  numbers  of  the  sockets 
rather  than  the  pin  numbers  of  the  14-pin  devices  used. 


Summary 

The  Dual  Processor  Card  arbitrates  memory  accesses  and 
the  signals  which  provide  for  the  memory  refresh.  The 
arbitration  logic  selects  which  memory  access  or  memory 
refresh  operation  wilJ  take  place  and  locks  out  other  re¬ 
quests  until  the  operation  is  completed.  The  bus  and 
control  signal  logic  uses  signals  from  the  arbitration 
logic  and  from  both  processors  to  generate  control  signals 
and  to  control  the  flow  of  data  on  the  address  and  data 
buses . 

The  design  of  these  two  parts  of  this  Card  are  not 
unique.  It  would  be  possible  to  implement  the  functions 
performed  by  the  Card  using  a  different  design.  It  would 
be  possible  to  use  one  processor  as  the  only  source  for 
the  refresh  signals  and  to  place  the  second  processor  in 
a  mode  such  that  it  could  make  memory  accesses  on  a  non¬ 
interference  basis.  A  design  such  as  this  would  increase 
average  access  time  for  at  least  the  second  processor,  even 
so,  the  configuration  could  be  implemented.  Other  alter¬ 
natives  are  feasible,  but  allowing  for  the  shared  memory 
to  be  accessed  on  a  first-come  first-served  basis  appeared 


to  be  the  best  alternative. 


Ill .  Local  Card 


The  Local  Card  interfaces  with  and  is  controlled  by 
the  X  processor.  It  was  designed  to  provide  four  RS-232C 
compatible  input/output  ports  to  interface  with  either 
Data  Communications  Equipment  ( DCE)  or  Data  Terminal  Equip¬ 
ment  (DTE) . 

This  chapter  will  describe  the  circuitry  of  the  Local 
Card.  Also  the  unusual  features  of  the  Card  will  be  dis¬ 
cussed  and  how  the  features  can  be  modified  to  provide 
greater  flexibility  in  the  Card.  The  operational  aspects 
which  must  be  considered  when  using  the  Card  will  be  pre¬ 
sented.  The  summary  section  will  review  the  material  dis¬ 
cussed  and  suggest  several  alternatives. 

Local  Card  Circuitry 

This  section  addresses  the  various  parts  of  the  cir¬ 
cuitry  on  the  Local  Card.  The  discussion  on  these  parts 
will  be  in  the  following  order:  address  and  control  signal 
drivers,  data  bus  drivers,  address  decoding,  Counter  Timer 
Circuit  (CTC)  signals,  2651  Programmable  Communications 
Interface  (PCI)  signals  and  interrupt  handling.  There  is 
a  certain  amount  of  interdependence  of  signals  so  at  certain 
times  references  to  signals  will  be  made,  which  have  not 
yet  been  explained.  This  discussion  will  attempt  to  mini¬ 
mize  this  occurrence. 

Address  and  Control  Signal  Drivers.  All  the  address 


20 


lines  and  control  signals  to  and  from  the  X  processor  board 
are  buffered  through  Hex  Bus  Drivers.  These  signals  and 
their  directions  are  illustrated  in  Figure  3-1.  The  drivers 
which  are  used  are  74LS367  Hex  Bus  Drivers  and  both  con¬ 
trol  signals  are  tied  to  ground,  since  the  signals  are 
continuously  driven.  The  A7  -  AO  signals  are  used  in  the 
address  decoding  process.  The  Wl?  signal  is  inverted  and 
used  to  control  the  direction  of  data  flow  through  the  bi¬ 
directional  data  bus  buffers.  The  Rt)  signal  is  applied 
to  the  CTC's  and  to  the  2651  PCI's  and  is  used  when  writing 
to  and  reading  from  those  devices.  The  lORQ  and  MY  signals 
are  used  in  the  address  decoding  circuitry  and  in  the  inter¬ 
rupt  handling  circuitry.  The  Interrupt  Enable  Input  (IEI) 
and  Interrupt  Enable  Output  (IEO)  are  used  in  the  inter¬ 
rupt  handling  circuitry  and  in  controlling  the  interrupts 
initiated  by  other  Local  Cards.  The  CLK  signal  is  inverted 
and  applied  to  the  8214  Priority  Interrupt  Control  Unit 
( PICU)  and  the  CTC’s.  The  CLK/2  signal  is  applied  to  the 
external  timer  input  of  each  of  the  four  CTC  channels, 
as  part  of  the  Baud  Rate  generation  process.  The  circui¬ 
try  associated  with  the  data  bus  drivers  will  be  covered 
next. 

Data  Bus  Drivers.  Two  Intel  8216  4-Bit  Parallel 
Bi-Directional  Bus  Drivers  were  chosen  as  the  drivers  of 
the  data  bus.  Figure  3-2  shows  the  circuitry  and  signals 
immediately  a  part  of  the  data  bus  and  its  controlling 
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circuit.  The  data  bus  side  of  each  device  is  connected 
to  the  X  processor  data  bus,  while  each  data  in/data  out 
pair  had  their  pins  connected  which  were  in  turn  connected 
to  each  CTC  and  to  each  2651  PCI  to  allow  data  transfer 
to  these  devices.  As  stated  before  the  WR  signal  is  in¬ 
verted  and  is  applied  to  the  DIEN  control  to  define  the 
direction  the  data  bus  is  driven.  Figure  3-2  also  shows 
that  if  any  of  the  CTC,  the  2651  PCI  or  the  8214  PICU  is 
enabled  with  a  low  signal  or  if  the  AINT  (acknowledge  in¬ 
terrupt)  is  high  then  the  chip  select  for  both  data  bus 
drivers  will  be  driven  low,  thus  enabling  the  drivers. 

This  completes  the  discussion  on  the  data  bus  drivers, 
while  the  next  subsection  deals  with  the  address  decoding 
circuitry. 

Address  Decoding.  A  74LS138  3-to-8  Line  Decoder  is 
the  principal  device  used  in  the  decoding  of  address  lines 
A7-A0.  Each  Local  Card  requires  that  25  addresses  be 
decoded  for  addressing  the  various  devices  on  the  Card. 

Each  of  the  CTC's  and  the  2651  PCI  required  four  addresses, 
while  the  8214  PICU  in  the  interrupt  handling  circuitry 
required  one  address.  Figure  3-3  shows  the  circuitry  in¬ 
volved  in  the  address  decoding  process.  Address  lines  A1 
and  AO  were  applied  to  the  CTC’s' and  the  2651  PCI  as  chan¬ 
nel  selects  and  internal  register  selects,  respectively. 
Address  lines  A4  -  A2  were  applied  to  the  3  select  inputs 
of  the  3-to-8  Line  Decoder  to  develop  the  true  low  chip 
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Fig.  3-3.  Address  Decoding  Circuitry 


enable  signals  for  the  CTC's,  the  2651  PCI's  and  the  8214 
PICU.  Address  lines  A7  -  A5  are  applied  to  the  3-to-8 
Line  Decoder  enables  as  required  to  have  the  Decoder  re¬ 
spond  to  a  certain  address  space.  Since  the  Local  Card 
requires  25  unique  addresses  and  it  takes,  at  least,  5 
address  lines  to  generate  those  addresses,  then  by  pro¬ 
perly  wiring  address  lines  A7  -  A5,  8  separate  Local  Cards 
can  be  supported  under  the  Z-80  Input/Output  addressing 
capabilities.  In  the  Local  Card,  which  was  implemented, 

A7  -  A5  were  set  to  place  the  address  space  of  the  Card  in 
the  lowest  eighth  of  the  address  space  of  the  eight  address 
lines.  Finally,  since  the  IORQ  is  also  active  during  the 
interrupt  acknowledge  cycle,  the  Ml  signal  is  logically 
combined  as  shown  to  insure  that  the  Decoder  only  operates 
during  an  input  or  ouput  cycle.  This  concludes  the  dis¬ 
cussion  relating  to  the  address  decoding  circuitry.  The 
next  subsection  deals  with  the  CTC. 

Counter  Timer  Circuit.  The  Counter  Timer  Circuit  is 
used  with  the  internal  baud  rate  generation  capabilities 
of  the  2651  PCI  to  provide  wide  flexibility  in  the  choice 
of  baud  rates  under  which  the  2651  will  operate.  Figure 
3-4  shows  which  signals  are  applied  to  each  of  the  two 
CTC's.  Appropriately  the  CTC’s  are  designated  #1  and  #2. 
The  signals  shown  in  the  Figure  are  for  CTC  Ml.  The 
signals  for  CTC  M2  are  the  same  except  for  the  chip  enable 
and  the  zero  timeout  pins.  CTC  Ml  provides  the  timing  for 
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the  first  two  of  the  2651  PCI  (henceforth,  called  USART's), 
while  CTC  #2  provides  the  timing  signals  for  USART's  #3 
and  #4.  The  Figure  provides  the  number  and  name  of  each 
of  the  28  pins  of  the  CTC  along  with  the  name  or  destina¬ 
tion  of  the  signal  at  that  pin.  Therefore,  the  Figure 
should  be  self-explanatory  so  that  discussion  will  continue 
with  the  2651  Programmable  Communications  Interface. 

2651  Programmable  Communications  Interface  (PCI) . 

The  2651  PCI  was  chosen  as  the  Universal  Synchronous/Asyn¬ 
chronous  Receiver/Transmitter  (USART)  for  the  Local  Card. 
Four  USART's  are  used  on  each  card  to  provide  four  full 
duplex  RS-232C  channels.  Each  of  these  USART's  use  almost 
the  same  set  of  signals  with  the  exception  of  the  chip 
enable,  baud  rate  clock  input,  TxRDY,  and  RxRDY .  The 
sources  and  destinations  for  these  four  pins  vary  slightly 
among  the  four  USART's.  Figure  3-5  illustrates  the  signals 
being  applied  to  USART  #1.  The  Figure  provides  the  name 
and  number  of  each  pin  on  the  chip  along  with  either  name, 
source  or  destination  of  the  signal  at  that  pin.  This 
Figure  is  also  self-explanatory,  so  that  the  discussion 
will  continue  on  to  the  interrupt  handling  circuitry. 

Interrupt  Handling.  After  the  2651  PCI  has  completed 
a  data  transfer  in  or  out,  an  interrupt  will  be  issued  by 
pulling  the  TxRDY  or  the  RxRDY  low.  Since  there  are  four 
of  these  USART’s  on  the  Card,  it  is  necessary  to  prioritize 
the  interrupts  and  develop  the  vectored  interrupt  address . 
These  functions  are  performed  through  the  use  of  the  Intel 
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8214  Priority  Interrupt  Control  Unit,  the  Intel  8212  Eight- 
Bit  Input/Output  Port  and  several  simple  gates.  Figure  3- f 
is  a  schematic  of  this  interrupt  handling  circuitry.  The 
8214  PICU  can  prioritize  among  eight  different  interrupts. 

The  request  lines  are  designated  R7  -  RO  where  an  interrupt 
on  R7  has  the  highest  priority.  The  RxRDY  signals  of 
USART's  1-4  are  input  at  R7  -  R4,  while  the  TxRDY  signals 
are  input  at  R3-R0.  Thus,  USART  #1  RxRDY  has  the  highest 
priority,  while  USART  #4  TxRDY  has  the  lowest  priority. 

The  Status  Group  Select  (SGS)  signal  and  the  B2,  Bl,  and 
BO  inputs  are  used  to  enable  various  priority  levels  and 
above;  however,  since  the  Card  requires  the  eight  inter¬ 
rupt  lines,  SGS  is  tied  high  enabling  all  interrupts.  The 
Master  Interrupt  Enable  (INTE)  and  the  Enable  This  Level 
Group  (ETLG)  pins  are  tied  to  the  Interrupt  Enable  Input 
(IEI) .  The  Enable  Next  Level  Group  (ENLG)  becomes  the 
Interrupt  Enable  Out  (IEO)  for  this  Card.  Also,  the  Enable 
Level  Read  (ELR)  is  tied  low  to  allow  reads  at  this  chip 
at  any  time.  The  PICU  is  enabled  by  writing  to  its  port 
address.  In  this  particular  design,  an  OUT  instruction 
to  address  OOOIIOXX2  would  provide  the  required  Enable 
Current  Status  (ECS)  signal.  After  the  8214  has  been  en¬ 
abled,  the  highest  prior  interrupt  pending  or  the  first  in¬ 
terrupt  to  the  device  would  cause  the  8214  to  issue  an  inter¬ 
rupt  (INT)  and  encode  the  priority  level  of  the  interrupt  on 
signals  A2,  Al,  and  AO.  With  the  Mode  set  low  and  Device 
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Fig.  3-6.  Interrupt  Handling  Circuitry 


Fig.  3-7.  Interrupt  Requcst/Acknowledge  Cycle  (Ref  17) 

Select  2  set  high,  the  data  from  the  8214  is  gated  into 
the  appropriate  latches  after  being  inverted.  The  con¬ 
figuration  as  shown  set  DI8,  DI7,  DI6,  DI5,  and  Dll  to  0, 
while  DI4  =  A2,  DI3  =  Al,  and  DI2  =  AO.  When  an  interrupt 
acknowledge  is  recognized  and  processed,  then  the  interrupt 
vector  will  be  0000XXX0  corresponding  to  an  even  address 
in  the  jump  table  for  Z-80  vectored  interrupts.  The  XXX 
will  be  111  for  an  R7  interrupt  and  000  if  the  interrupt 
had  been  an  R0. 

The  interrupt  acknowledge  signal  is  developed  from 
the  IORQ  and  Ml  signals  of  the  microcomputer  and  the  Enable 
Next  Level  Group  (ENLG)  signal  from  the  8214.  Figure  3-7 
shows  how  the  CPU  responds  to  an  interrupt.  A  special  Ml 
cycle  is  generated  with  two  wait  states  and  IORQ  goes  low. 
These  signals  are  inverted  and  ANDed  together  and  then  this 


result  is  NAND'ed  with  the  inverse  of  ENLG.  ENLG  will  go 
low  when  the  8214  generates  an  interrupt.  The  result  is 
the  AINT  which  is  input  to  the  Device  Select  1  (DS1)  caus¬ 
ing  the  interrupt  vector  to  be  put  out  on  the  data  bus. 

Then,  the  interrupt  handling  circuitry  is  re-enabled  by 
writing  to  the  8214  Enable  Current  Status  (ECS)  pin.  This 
concludes  the  discussion  on  the  interrupt  handling  circui¬ 
try.  A  complete  schematic  is  provided  in  Appendix  B. 
Inspection  of  the  schematic  will  reveal  the  existence  of 
line  drivers  and  receivers  associated  with  each  USART. 
Discussion  of  these  drivers  and  receivers  is  delayed  until 
the  features  section  of  this  chapter  because  the  configura¬ 
tion  of  the  drivers  and  receivers  is  dependent  on  the 
requirements  of  the  port.  Finally,  it  is  recognized  that 
the  design  of  some  of  the  circuitry  is  inefficient,  this 
is  primarily  due  to  the  availability  of  chips  and  the  desire 
to  get  the  device  working  first  and  efficient  later. 
Alternatives  to  the  design  are  provided  in  the  summary 
section . 

Features  of  the  Local  Card 

It  was  stated  that  more  than  one  Local  Card  can  be 
used  in  the  Universal  Network  Interface  Device.  This  is 
desirable  to  allow  for  adding  capability  to  the  system 
without  requiring  a  complete  re-design.  The  modular  nature 
of  the  Local  and  Network  Cards  makes  this  idea  very  prac¬ 
tical.  To  add  more  cards,  it  would  be  necessary  to  perform 
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receivers  are  Motorola  MCl489's.  These  devices  are  in 
common  use  in  the  application  of  RS-232C  interfaces. 

Figure  3-8  shows  the  signal  arrangement  for  the  port  con¬ 
figured  as  DTE  and  Figure  3-9  shows  the  signal  arrangement 
for  the  port  when  it  is  configured  as  DCE.  One  point  to 
note  is  that  the  connector  used  would  be  a  standard  25-pin 
female  RS-232C  connector.  Also  the  Card  could  be  config¬ 
ured  to  support  the  RS-232C  secondary  channel  through  the 
use  of  two  ports  instead  of  just  one.  This  concludes  the 
discussion  on  the  features  of  the  Local  Card.  The  last 
section  of  this  chapter  will  present  an  overview  of  the 
operations  on  the  Local  Card. 

Local  Card  Operations 

This  section  addresses  how  the  Local  Card  is  used 
and  what  steps  must  be  performed  to  program  the  devices. 
Depending  on  how  timing  signals  are  supplied,  the  USART 
will  determine  the  programming  of  the  CTC's.  If  the  CTC's 
will  supply  the  timing  signals,  then  they  must  be  programmed, 
as  follows.  The  CTC  and  channel  are  selected  by  writing 
out  the  address  on  address  lines  A7-A0.  The  operating 
mode  is  selected,  in  this  case,  timer  mode  with  prescaler 
and  appropriate  triggering  to  start  the  timing  cycle. 

Then  a  time  constant  can  be  loaded  as  the  next  word  written 
to  the  channel.  These  operations  would  be  done  for  each 
channel  of  the  two  CTC's  providing  timing  signals  to  the 
USART' s.  After  the  CTC's  have  been  programmed,  then  the 
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USART's  would  be  programmed.  Details  for  programming  these 
devices  can  be  found  in  the  appropriate  Signetics  product 
specifications;  however,  to  give  some  appreciation  of  the 
devices  the  following  discussion  is  presented.  Assuming 
that  the  ports  are  supporting  asynchronous  communication 
then  the  first  step  would  be  to  load  the  settings  into  the 
two  mode  registers.  This  would  be  accomplished  by  output¬ 
ting  address  00000001  for  USART  Ml  and  selection  of  the 
appropriate  settings  to  specify  number  of  stop  bits,  parity, 
character  length,  mode  and  baud  rate  factor.  Outputting 
the  same  address  would  allow  the  second  mode  register  to  be 
loaded.  The  second  mode  register  controls  which  clocks 
are  used  and  selects  the  baud  rate.  Then,  the  command 
register  is  loaded  by  writing  out  to  address  00000011. 

The  command  register  is  used  to  set  operating  mode,  Request 
to  Send  (RTS) ,  Data  Terminal  Ready  (DTR) ,  reset  receive 
control  and  transmit  control.  The  last  two  items  are  used 
to  enable  the  receiver  and  transmitter,  respectively.  If 
both  are  set,  then  the  receiver  will  receive  data  when  the 
DCD  input  is  low  and  the  transmitter  will  transmit  data 
when  the  CTS  input  is  low.  After  the  devices  have  been 
initially  programmed  and  the  support  software  is  available 
then  a  write  to  the  8214  Enable  Current  Status  would  allow 
the  Card  to  process  interrupts  and  to  transfer  data.  This 
concludes  the  description  of  the  operational  features  of 
the  Local  Card. 
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This  chapter  was  intended  to  provide  the  reader  with 
a  detailed  review  of  the  circuitry  and  operation  of  the 
Local  Card.  The  material  in  the  chapter  dealt  with  the 
buffering,  port  decoding  and  interrupt  handling  circuitry. 
The  designs  used  for  these  three  types  of  circuitry  can  be 
modified  rather  easily.  The  extensive  resources  available 
to  the  digital  designer  allow  many  different  ways  for 
implementing  different  functions.  The  designs  selected 
for  these  three  circuits  were  chosen  on  the  basis  of  sim¬ 
plicity  and  flexibility.  The  CTC  and  2651  PCI  perform  more 
complicated  functions;  however,  there  are  other  devices 
available  which  perform  similar  functions.  The  application 
of  control  signals  would  be  different,  if  other  devices 
were  used,  but  not  greatly.  Therefore,  the  design  of  this 
Card  could  be  changed,  yet  still  accomplish  the  required 
functions . 
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This  chapter  deals  with  the  Network  Card  in  a  manner 


similar  to  the  previous  chapter.  The  various  parts  of 
the  circuitry  will  be  described  as  they  fit  within  the 
following  function:  address  and  control  signal  drivers, 
data  bus  and  the  associated  control  circuitry,  address 
decoding,  the  Counter  Timer  Circuit  and  the  Z80-Serial 
Input/Output  device.  The  jumpering  options  and  the  con¬ 
figuration  of  the  port  are  also  discussed.  A  brief 
discussion  on  the  Network  Card  operations  is  then  presented. 
The  last  section  summarizes  the  chapter  and  discusses 
alternatives . 

Network  Card  Circuitry 

This  section  provides  a  detailed  description  of  the 
circuitry  of  the  Network  Card.  The  design  is  very  similar 
in  general  appearances  to  that  of  the  Local  Card.  There 
are,  however,  several  aspects  to  the  two  cards  where  dif¬ 
ferent  designs  were  implemented  due  to  differences  in  the 
modes  of  operations.  The  first  part  of  the  circuitry  to 
be  covered  is  the  address  bus  and  control  signal  drivers. 

Address  Bus  and  Control  Signal  Drivers.  Using  the 
same  design,  as  was  used  on  the  Local  Card,  the  address 
lines  and  control  signals  are  buffered  by  using  74LS367 
Hex  Bus  Drivers.  These  drivers  are  used  to  minimize  load¬ 
ing  on  the  system  buses  and  to  insure  high  quality  signals 
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are  returned  to  the  Y  processor.  Figure  4-1  illustrates 
which  signals  are  buffered  by  use  of  the  74LS367's.  The 
control  lines  are  tied  low  to  enable  the  drivers  all  the 
time.  Address  lines  A7  -  AO  are  used  in  the  address  decoding 
circuitry.  The  WR,  IORQ,  Ml,  and  the  MREQ  signals  are 
combined  with  other  signals  generated  on  the  Card  to  con¬ 
trol  the  data  bus.  The  RD  signal  is  used  by  the  Counter 
Timer  Circuit  (CTC)  and  the  Serial  Input/Output  when  data 
is  being  transferred  to  and  from  these  devices.  The  RESET 
signal  is  used  by  the  CTC  and  the  SIO  to  restart  the  de¬ 
vices.  The  Interrupt  Enable  Input  (IEI)  and  the  Interrupt 
Enable  Output  (IEO)  are  used  in  establishing  a  daisy  chain 
interrupt  scheme.  The  CLK  signal  is  inverted  and  is  used 
to  provide  clock  signals  to  the  CTC  and  the  SIO.  The  INT 
signal  is  used  by  the  SIO  to  interrupt  the  Y  processor. 

And  the  WAIT  signal  is  used  by  the  two  SIO  WAIT/READY 
pins  to  synchronize  the  CPU  to  the  SIO  data  rate.  The 
next  subsection  will  describe  the  data  bus  and  the  associ¬ 
ated  control  signals. 

Data  Bus  and  Controlling  Circuitry.  Intel  8216  4-Bit 
Parallel  Bi-Directional  Buffers  were  selected  to  buffer 
the  data  bus  signals.  Figure  4-2  is  a  schematic  of  the 
circuitry  used  to  provide  the  Chip  Select  (CS)  and  the 
Data  In  Enable  (DIEN)  signals  to  the  buffers.  The  8216' s 
were  wired  to  have  the  data  bus  pins  tied  to  the  system 
bus,  while  the  data  input  and  data  output  pins  were  con¬ 
nected  and  provided  the  data  bus  on  the  Card. 


40 


SYSTEM  BUS 


Data  Bus  Controlling  Circuitry 


The  CS  signal  enables  the  buffers,  while  the  DIEN 
signal  controls  the  direction  of  the  data.  If  DIEN  is 
high,  data  can  be  written  into  the  Card;  however  when  DIEN 
is  low,  data  can  be  read  from  the  Card.  Data  is  transferred 
between  the  Y  processor  and  the  Network  Card  during  reads 
and  writes  to  the  CTC  or  SIO  and  during  the  handling  of 
interrupts.  When  either  the  CTC  or  SIO  is  enabled,  the 
CS  pin  will  be  driven  low.  The  WR  signal  is  inverted  and 
wired  to  an  OR  gate  causing  DIEN  to  be  high  during  write 
operations  and  low  during  read  operations.  The  remaining 
part  of  the  circuitry  shown  in  Figure  4-2  controls  data 
flow  during  interrupts.  The  IEO  is  usually  high,  which 
causes  a  low  at  Q  of  the  flip-flop.  This  low  signal  does 
not  affect  the  data  flow.  When  an  interrupt  occurs,  the 
SIO  pulls  the  IEO  low  until  the  service  routine  for  the 
interrupt  is  completed  and  a  Return  from  Interrupt  Instruc¬ 
tion  (RETI)  has  been  placed  on  the  data  bus  and  been  recog¬ 
nized  by  the  SIO.  The  interrupt  from  the  SIO  causes  the 
CPU  to  initiate  an  interrupt  acknowledge  cycle.  The  timing 
of  signals  involved  in  this  cycle  was  presented  in  Figure 
3-7.  The  preset  signal  is  removed  from  the  flip-flop  when 
IEO  goes  low,  and  when  Ml  and  IORQ  are  low  a  high  is  pre¬ 
sent  at  the  output  of  the  74LS21  which  causes  the  CS  signal 
to  go  low.  Meanwhile,  the  Q  output  from  the  flip-flop 
is  still  low,  because  the  flip-flop  will  only  respond  to 
a  leading  edge  trigger.  Therefore,  DIEN  will  be  low  allow¬ 
ing  the  interrupt  vector  to  be  placed  on  the  data  bus  by 
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the  SIO  and  to  be  read  by  the  CPU.  When  Ml  and  IORQ 
return  to  a  high  state,  CS  goes  high  and  Q  triggered  to 
go  high.  The  high  Q  signal  will  allow  data  to  be  written 
into  the  Card  when  CS  is  true.  The  CS  will  go  true  when 
both  MREQ  and  Ml  are  low.  Thus,  data  is  available  to  the 
SIO  for  decoding  while  instructions  are  being  fetched  from 
memory.  The  SIO  must  be  allowed  to  monitor  the  data  bus, 
because  it  recognizes  the  completion  of  its  service  routine 
by  observing  the  two  op  code  instruction  RETI  being  placed 
on  the  data  bus,  while  its  IEI  is  high  and  its  IEO  is  low. 
After  the  SIO  recognizes  the  RETI  instruction,  the  IEO 
is  forced  high,  disabling  the  AND  gate  and  presetting  the 
Q  output  low.  This  returns  the  controlling  circuitry  to 
its  inactive  condition  and  allows  the  resumption  of  the 
other  read  and  write  control.  This  concludes  the  discus¬ 
sion  on  the  data  bus  control  circuitry.  The  next  subsec¬ 
tion  will  present  the  description  of  the  address  decoding 
circuitry. 

Address  Decoding  Circuitry.  The  mode  of  address 
decoding  on  the  Network  Card  is  identical  to  that  on  the 
Local  Card.  The  A1  and  AO  signals  are  applied  to  the  CTC 
and  the  SIO,  while  the  circuitry  and  wiring  connections 
shown  in  Figure  3-3  are  used  to  develop  the  CTC  and  SIO 
Chip  Enable  (CE) .  Referencing,  Figure  3-3  the  SIO  CE  is 
available  from  the  YO  pin  and  the  CTC  CE  is  available  from 
the  Yl  output.  Therefore  the  addresses  to  the  SIO  and  the 


CTC  are  OOOOOOXX  and  000001XX,  respectively.  Other  than 
these  changes  the  design  of  the  address  decoding  logic  is 
identical  to  that  described  in  the  discussion  on  the  Local 
Card  circuitry.  The  next  subsection  v:ill  describe  the 
Counter  Timer  Circuit. 

Counter  Timer  Circuit  Signal.  The  Z 80 -CTC  is  u^ed  in 
the  Network  Card  to  provide  timing  signals  to  the  Z80-SIO. 
Figure  4-3  shows  the  signals  applied  to  the  CTC.  The 
signals  applied  to  the  CTC  are  the  aata  bus,  the  CE,  Al, 

AO,  Ml,  IORQ,  and  RD.  These  signals  are  also  used  on  the 
CTC 1 s  of  the  Local  Card.  The  timing  signals  input  at  the 
CLK/TRG^  and  CLK/TRGQ  pins  are  CLK/2  and  CLK/5 .  These 
signals  are  generated  by  inverting  the  CLK  signal  and 
inputting  the  result  into  a  74LS90  Decade  Counter.  The 
CLK  signal  is  applied  to  Input  B.  The  Input  A  and  QD  pins 
are  tied  together.  This  configuration  provides  a  CLK/2 
signal  at  Q  and  a  CLK/5  at  Q_.  The  CLK/2  signal  is  applied 
to  the  CLK/TRG2  to  act  as  a  trigger  signal  if  it  is  desired 
to  use  that  channel.  The  three  Zero  Count  or  Timeout 
signals  are  made  available  at  the  RxCA,  TxCA,  and  RxTxCB 
pins  to  provide  a  varied  selection  of  programmable  timing 
sources  for  these  inputs.  The  system  RESET  signal  is 
connected  to  reset  the  CTC  during  a  system  reset.  This 
completes  the  discussion  related  to  the  CTC,  the  next 
section  addresses  the  Z80-SIO. 

Z-80  Serial  Input/Output.  This  device  provides  the 


Network  Card  with  its  flexibility  and  capacity  to  handle 
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Fig.  4-3.  Counter  Timer  Circuit  Signals 
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high  data  rates  and  different  protocols.  This  subsection 
describes  the  signals  and  the  configuration  of  the  data 
transmission  and  reception  pins  in  order  to  meet  the  RS-422/ 
423  specification.  The  dual  channels  of  the  SIO  were 
configured  such  that  Channel  A  was  wired  as  DTE  and  Channel 
B  was  wired  as  DCE.  This  configuration  allows  testing  of 
the  Card  by  simulating  a  loop  network  such  that  messages 
transmitted  by  Channel  A  will  be  received  by  Channel  B. 
Figure  4-4  provides  a  schematic  of  the  signals  to  the  SIO 
and  the  configuration  of  the  two  ports.  The  W/RDY  signal 
is  used  to  control  data  flow  to  and  from  the  CPU.  The 
Card  is  configured  such  that  one  of  the  CTC  channels  is 
used  as  a  timing  source  for  the  receive  and  transmit  clocks 
for  both  channels .  The  dotted  lines  in  the  drawings  show 
which  signals  of  each  port  correspond  to  which  signals  in 
the  other  port  in  this  DTE/DCE  configuration.  The  SYNC 
signals  are  not  needed  to  support  the  Card  operation  as 
designed.  This  concludes  the  discussion  on  the  SIO  signals 
and  the  port  configuration.  A  complete  schematic  is  in¬ 
cluded  as  Appendix  C.  This  completes  the  description  of  the 
Network  Card  Circuitry.  The  next  section  describes  the 
features  of  the  Card. 

Features  of  the  Network  Card 

The  Network  Card  was  designed  to  be  a  very  flexible 


interface  to  communications  networks.  The  flexibility 
of  the  interface  is  due  primarily  to  the  Z80-SIO.  This 
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device  features  two  independent  full  duplex  channels,  data 
rates  of  up  to  550  Kilobits/sec,  receiver  registers  qua- 
druply  buffered,  transmitter  doubly  buffered,  asynchronous 
operation.  Binary  Synchronous  operation,  High-Level  Data 
Link  Control  (HDLC)  or  IBM  Synchronous  Data  Link  Control 
(SDLC)  operation,  modem  controls,  error  checking,  and 
daisy  chain  priority  interrupt  logic  including  interrupt 
vectoring.  More  data  on  this  device  can  be  obtained  from 
the  Z80-SIO  Product  Specification  (Ref  18) .  Data  on  the 
above  mentioned  Data  Link  Controls  is  available  in  refer¬ 
ences  15  and  16.  Several  Network  Cards  can  be  supported 
in  the  UNID;  however,  the  high  data  rates  would  preclude 
operation  at  the  highest  of  data  rates.  In  fact,  the  cur¬ 
rent  design  will  not  meet  the  design  goal  of  1.5  Megabits/ 
sec,  but  the  550  Kilobits/sec  should  be  more  than  fast 
enough  to  demonstrate  that  the  basic  concept  of  the  UNID 
design  is  feasible.  The  1.5  Megabits/sec  should  be  achiev¬ 
able  with  a  device  such  as  the  Signetics  2652  Multi¬ 
protocol  Communications  Controller  (Ref  15)  using  direct 
memory  access  techniques  to  transfer  the  data  into  and  out 
of  memory.  Under  some  applications  involving  the  transla¬ 
tion  of  data  from  one  character  code  to  another,  the  current 
8-bit  processors  may  not  be  able  to  process  the  data  in  the 
allotted  time,  then  one  of  the  new  generation  of  16-bit 
processors  could  be  considered  to  support  the  operations 
on  the  network  side  of  the  device.  This  concludes  the  dis¬ 
cussion  on  the  Network  Card's  features,  the  next  section 


49 


will  review  the  operational  aspects  of  the  Network  Card. 

Network  Card  Operations 

This  section  will  provide  a  brief  overview  of  the 
operational  configuration  of  the  Network  Card.  This  section 
will  specifically  address  programming  of  the  CTC  and  the 
SIO.  Programming  of  the  CTC  was  covered  in  a  previous 
chapter,  but  the  Network  Card  is  designed  to  use  the  CTC  in 
a  different  mode.  On  the  Local  Card,  the  anticipated  use  of 
the  CTC  is  in  the  timer  mode,  where  the  system  clock  is 
prescaled  and  is  used  to  decrement  the  down  counter.  How¬ 
ever,  on  the  Network  Card,  the  CTC  operates  in  the  counter 
mode.  In  this  mode,  the  CLK/TRG  signal  is  used  to  decre¬ 
ment  the  down  counter,  which  provides  the  Zero  Count/Time 
Out  signal  which  is  used  as  a  clock  signal  for  the  SIO. 

This  mode  is  programmed  by  outputting  the  address  which 
develops  the  CTC  CE  signal  and  selects  the  proper  channel. 
Then  the  required  data  is  placed  on  the  data  bus  and  writ¬ 
ten  to  the  channel  control  register  to  select  counter  mode 
and  its  specific  options.  After  this  step,  an  8-bit  time 
constant  can  be  loaded  into  the  Time  Constant  register  to 
be  used  as  a  divisor  of  the  signal  on  the  CLK/TRG  input. 

The  device  does  not  use  the  CTC  to  generate  interrupts; 
therefore,  no  interrupt  vector  is  loaded  nor  are  inter¬ 
rupts  enabled. 

The  programming  of  the  SIO  is  described  in  reference 
18  and  will  only  be  summarized  here.  The  design  of  the 


Network  Card  provides  that  the  SIO  interact  with  the  Y 
processor  through  a  series  of  programmed  interrupts.  Before 
the  Network  Card  can  become  operational,  it  must  be  initial¬ 
ized.  The  initialization  process  involves  performing  I/O 
writes  to  the  eight  write  registers  in  each  channel.  The 
first  write  to  an  SIO  channel  will  cause  the  data  bus  to 
be  written  into  Write  Register  0.  Writes  to  this  register, 
include  a  3-bit  pointer  to  the  location  of  the  next  read 
or  write.  For  example,  if  the  lower  3-bits  of  the  data 
word  were  101,  then  the  next  write  to  that  channel  would 
cause  data  to  be  written  into  Write  Register  5.  Besides 
the  addressing  function.  Write  Register  0  generates  con¬ 
trols  often  used.  Write  Register  1  enables  various  inter¬ 
rupts  and  allows  programming  of  the  W/RDY  signal.  Write 
Register  2  contains  the  interrupt  vector.  If  the  "status 
affects  vector"  feature  is  programmed,  then  bits  D3,  D2 
and  D1  might  be  changed  subject  to  the  type  of  interrupt 
being  generated.  Write  Register  3  sets  receive  parameters 
and  the  number  of  bits/character.  Write  Register  4  sets 
the  parity,  stop  bits,  sync  function  and  the  clock  pre¬ 
scaler  for  sampling  the  data.  Write  Register  5  sets  the 
transmit  parameters  and  the  number  of  bits  being  transmitted 
per  character.  Also  bit  7  of  this  register  controls  the 
DTR  output,  DTR  will  be  the  complement  of  this  bit.  Write 
Registers  6  and  7  define  the  SYNC  characters  used  in  syn¬ 
chronous  mode,  while  just  register  6  is  used  to  define  the 
flag  character  when  in  SDLC  mode. 


To  complement  the  Write  Registers,  there  are  Read 


Registers  to  provide  status  information  on  each  channel. 
First,  there  is  Read  Register  2  in  Channel  B  only.  This 
register  reflects  the  current  status  of  Write  Register, 
also  only  in  Channel  B,  which  contains  the  interrupt  vec¬ 
tor.  Read  Register  0  provides  the  status  of  the  receiver 
and  transmitter.  Read  Register  1  contains  information 
relating  to  the  end  of  transmit  or  receive  operation.  The 
status  bits  in  this  register  sometimes  only  apply  in  cer¬ 
tain  modes  of  operation.  After  the  initialization  process 
is  completed,  the  transmitter  will  become  active  upon  re¬ 
ceipt  of  the  CTS  signal,  while  the  receiver  will  become 
active  after  receipt  of  the  D CD  signal.  This  concludes  the 
discussion  of  the  SIO  operation. 

Summary 

This  chapter  reviewed  the  circuitry  and  operations 
of  the  Network  Card.  The  CTC  provides  the  source  of  timing 
signals,  while  the  SIO  receives,  transmits,  and  processes 
the  data.  The  remainder  of  the  circuitry  on  the  Card 
supports  buffering  and  control  of  the  buses  and  port  address 
decoding.  All  of  these  functions  could  be  accomplished 
by  other  hardware.  However,  the  configuration  of  the  Card 
would  be  changed  completely.  The  SIO  is  the  basis  for  the 
design  of  the  Network  Card,  so  that  the  Network  Card  can  be 
considered  to  be  an  SIO  and  the  supporting  circuitry. 

Other  Data  Link  Control  Chips  do  exist  (Ref  5) ,  but  their 
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features  vary  widely.  Therefore,  if  the  Network  Card  were 
designed  around  one  of  these  other  chips,  the  supporting 
circuitry  would  have  to  be  modified  accordingly. 


V.  Universal  Network  Interface  Device 


This  chapter  provides  an  overview  of  the  prototype 
Universal  Network  Interface  Device  (UNID) .  This  prototype 
was  constructed  for  the  purpose  of  testing  the  feasibility 
of  a  flexible  network  interface  device.  As  such,  the 
device  meets  the  requirements  for  testing  and  for  making 
modifications  rather  easily.  Even  so,  the  design  and 
construction  of  the  device  is  far  removed  from  a  fieldable, 
production  version.  With  this  point  made  clear,  the  con¬ 
tents  of  this  chapter  will  be  outlined. 

The  first  section  describes  the  overall  architecture 
of  the  device.  The  second  section  addresses  the  proce¬ 
dures  which  must  be  accomplished  prior  to  using  the  device 
as  a  message  processor.  This  section  deals  with  both  the 
hardware  and  software  procedures  required.  The  third 
section  reviews  several  specific  features  relating  to  the 
implementation  of  the  device.  These  features  include  the 
generation  of  the  clock  signals,  an  addressing  PROM  used 
on  the  shared  memory  card,  the  mini-disk  interface  and  the 
wiring  used  in  the  device. 

■Overall .  A £C hit egtur e 

The  device  consists  of  two  microcomputer  boards  which 
share  a  16K  block  of  dynamic  RAM  memory.  Accesses  to  the 
shared  memory  are  arbitrated  by  the  Dual  Processor  Card, 
which  also  processes  the  refresh  signals  generated  by  each 
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Z-80  Central  Processing  Unit  (CPU) ,  to  provide  the  neces¬ 
sary  refresh  signals  to  the  shared  memory.  The  micro¬ 
computer  boards  were  designated  the  X  and  Y  processors. 

The  X  processor  would  interface  with  one  or  more  Local 
Cards  and  the  Y  processor  was  used  to  interface  with  net¬ 
work  traffic  through  a  Network  Card.  The  design  of  the 
Local  Card  includes  four  RS-232C  I/O  ports  plus  on-card 
programmable  timing  sources.  The  Network  Card  provides 
two  RS-422/423  channels  supported  by  on-card  programmable 
timing  sources. 

The  prototype  device  uses  these  cards  in  a  Zilog 
ZCC-9  Card  Cage.  This  card  cage  has  nine  card-slot  chassis 
which  provides  the  type  of  connectors  needed  to  mount 
the  Zilog  Z-80  series  cards.  These  connectors  are  numbered 
J1-J9.  The  card  cage  also  has  wire-wrap  pins  which  can 
be  interfaced  with  26-pin  ribbon  cable  connectors.  These 
connectors  were  used  to  interface  RS-232C  compatible  ter¬ 
minals  directly  to  the  microcomputer  boards  and  as  the 
interface  point  for  control  signals  to  be  applied  to  the 
device.  These  26-pin  connectors  are  numbered  J14-J21. 
Table  I  provides  a  list  of  the  cards  and  devices  which 
can  be  interfaced  through  each  of  these  connectors.  Each 
of  the  cards  and  plugs  used  with  these  connectors  are 
labeled  with  the  connector  number  to  minimize  confusion 
when  constructing  the  device.  Card-slot  J5  indicates 
a  Mini-Disk  interface.  This  interface  is  discussed  in  the 
last  section  of  this  chapter.  Connector  J20  is  used  for 
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TABLE  I 
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UNID  CONNECTOR  INTERFACES 


Connector  Number 

Card  or  Device 

J1 

Dual  Processor  Card 

J2 

Y-Processor  Card 

J3 

X-Processor  Card 

J4 

RAM  Memory  Board 

J5 

Mini-Disk  Interface 

J6 

- 

J7 

Network  Card 

J8 

- 

J9 

Local  Card 

J14 

_ 

JI5 

- 

J16 

Y-Processor  RS-232C  Interface 

J17 

- 

J18 

X-Processor  RS-232C  Interface 

J19 

- 

J20 

Device  Controls  Interface 

J21 


device  controls.  At  the  present  time,  these  controls 
consist  of  debounced  switches  which  provide  the  RESET 
signal  for  each  microcomputer  board. 

The  device  as  configured  does  not  have  its  own  power 
supply.  Power  in  the  form  of  +5V,  +12V  and  -12V  is  supplied 
by  an  exterior  power  supply.  The  device  draws  about  5 
amperes  from  the  5V  supply  and  less  than  .1  of  an  amp  from 
the  +12V  and  -12V  supplies.  This  concludes  the  discussion 
on  the  overall  architecture  of  the  device.  The  next  sec¬ 
tion  discusses  the  procedures  necessary  to  use  the  device 
as  a  message  processor. 

Procedures  Required  Before  Use 

This  section  provides  a  description  of  the  procedures 
necessary  before  using  the  device  as  a  message  processor. 
These  procedures  relate  to  the  types  of  hardware  inter¬ 
faces  used  and  to  the  type  of  software  required  to  support 
the  message  processing  function.  The  hardware  procedures 
will  be  addressed  first,  followed  by  the  software  proce¬ 
dures  . 

Hardware  Procedures.  The  procedures  involved  in 
supporting  the  message  processing  function  basically 
involve  the  numbers  and  types  of  interfaces  required. 
Depending  on  the  node  configuration,  which  the  device  is 
supporting,  there  could  be  many  hardware  variations  in 
the  device.  If  more  than  one  Local  Card  and  one  Network 
Card  were  required,  then  the  appropriate  jumpering  was 


required  to  insure  that  the  I/O  address  spaces  did  not 
conflict.  Also,  if  more  than  one  Local  Card  was  used, 
the  wired-in  interrupt  vector  addresses  would  have  to  be 
modified  so  that  the  interrupting  USART  was  being  serviced 
by  the  correct  routine. 

The  other  problem  requiring  hardware  modifications 
would  be  the  configuration  of  the  device  being  serviced 
by  a  given  port.  The  Local  Card  shall  be  considered  first. 
It  can  support  four  RS-232C  compatible  users,  presuming 
that  only  primary  channels  are  used.  However,  the  user 
might  require  full  duplex  service  over  the  primary  and 
secondary  channel,  this  would  require  two  I/O  ports. 

Thene  there  is  the  question  of  whether  the  UNID  is  appear¬ 
ing  as  Data  Communications  Equipment  or  as  Data  Terminal 
Equipment.  Depending  on  which  configuration  is  required 
will  define  how  the  signals  at  each  port  will  be  wired 
to  the  25-pin  RS-232C  female  connector.  The  Local  Card 
is  intended  to  be  used  to  support  asynchronous  data  trans¬ 
fer  with  lower  data  rate  users;  however,  the  2651  Pro¬ 
grammable  Communications  Interface  (USART)  can  support 
synchronous  communications.  If  this  feature  is  required, 
it  will  require  the  addition  of  one  or  possibly  two  addi¬ 
tional  signals.  These  signals  are  Transmitter  Signal 
Element  Timing  (DCE) / (DTE)  and  Receiver  Signal  Element 
Timing  (DCE) .  Whether  the  UNID  is  acting  as  DCE  or  as 
DTE,  will  determine  if  the  device  will  be  the  source  and/ 
or  destination  for  these  signals. 
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The  Network  Card  would  require  modifications  similar 
to  those  required  on  the  Local  Card.  The  service  support 
required  by  the  port  and  the  CTE/DCE  configuration  defines 
the  types  of  jumpering  required  to  support  each  device. 

The  drivers  used  on  the  Network  Card  are  Motorola  MC3487's, 
while  the  receivers  are  Motorola  MC3486's.  This  driver/ 
receiver  pair  is  designed  specifically  to  support  the 
balanced  and  unbalanced  voltages  associated  with  the 
RS-422  and  RS-423  Standards,  respectively.  Since  the 
Network  Card  is  primarily  to  support  synchronous  communica¬ 
tions,  the  Transmitter  Signal  Element  Timing  and  Receive 
Signal  Element  Timing  signals  must  be  accomodated.  The 
only  other  hardware  consideration  deals  with  loading  the 
software  operating  system.  In  a  production  version  of  the 
device  PROM's  or  ROM's  would  provide  the  method  for  soft¬ 
ware  loading.  For  a  given  type  of  service  a  different 
type  of  software  would  be  loaded.  The  next  subsection 
treats  the  software  aspect  in  greater  detail. 

Software  Procedures.  This  subsection  addresses 
procedures  required  for  software  support.  These  proce¬ 
dures  are  covered  in  the  following  order:  loading,  opera¬ 
ting  system,  initializing,  proposed  load  map  and  inter¬ 
processor  communications.  As  mentioned  in  the  hardware 
procedures  description,  the  operating  system  would  most 
likely  be  loaded  by  some  type  of  read-only  memory.  It 
would  not  be  cost-effective  to  provide  pre-loaded  operating 
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systems  for  all  possible  device  configurations,  therefore, 
some  method  is  required  to  modify  or  initialize  the  opera¬ 
ting  system. 

The  initialization  procedure  would  be  handled  by 
as  short  as  possible  section  of  code.  A  terminal  would 
have  to  be  connected  directly  with  each  of  the  microcomputer 
boards.  After  the  device  is  powered  up,  it  would  be  reset 
and  the  initialization  process  could  begin.  This  process 
would  deal  with  specifics  such  as  number  of  terminals, 

I/O  addresses,  vectored  interrupt  addresses,  baud  rates, 
numbers  of  stop  bits,  sync  characters  and  any  other  para¬ 
meters  needed  to  support  the  operating  system  and  the 
associated  communication  mode.  This  loading  and  initiali¬ 
zation  procedure  could  be  implemented  as  described;  however, 
an  alternative  method  would  be  to  include  a  terminal 
and  small  mass  storage  device  as  part  of  the  UNID.  This 
alternative  would  cause  a  significant  increase  in  the 
device's  cost,  but  it  would  probably  be  more  than  worth 
it  in  terms  of  flexibility  and  having  a  means  of  perform¬ 
ing  diagnostics  and  monitoring  message  traffic.  Either 
alternative  would  support  an  operating  system,  but  the 
latter  one  would  probably  be  superior  in  the  long  run. 

The  device  in  production  version  would  allow  the 
addition  of  memory  for  each  processor  or  to  increase  the 
size  of  the  shared  memory  block.  Suppose  that  the  device 
is  configured,  so  that,  each  processor  has  32K  of  memory 
and  the  shared  block  also  has  32K  bytes.  Then,  a  typical 


load  map  of  the  device  might  appear  as  shown  in  Figure  5-1. 
A  large  block  of  the  dedicated  memory  for  each  processor 
would  hold  the  operating  system.  For  both  processors, 
memory  would  be  required  to  hold  data  tables  and  as  a 
scratch  memory  to  perform  operations  on  messages.  The 
largest  part  of  the  shared  memory  would  contain  message 
data  being  held  for  transmission  to  the  Local  Card  or  to 
the  Network  Card.  There  would  also  be  a  portion  of  the 
shared  memory  allocated  to  such  tables  as  the  Local  Message 
Table,  the  Network  Message  Table,  and  the  Memory  Management 
Table.  These  tables  would  be  accessed  by  each  processor 
to  provide  a  means  of  controlling  message  flow  and  message 
parameter  flow  between  the  processors.  A  description  of 
how  accesses  to  these  tables  would  be  arbitrated  is  des¬ 
cribed  below. 

Consider  the  Local  Message  Table.  This  table  would 
deal  with  messages  going  to  the  Local  Card.  It  would  be 
used  to  pass  parameters  such  as  starting  address,  stopping 
address,  local  device  address,  and  operations  to  be  per¬ 
formed  on  the  message.  These  parameters  plus  two  software 
flags  would  be  used  to  control  access  to  each  entry. 

During  the  initialization  process,  one  of  the  software 
flags  would  be  set  to  deny  access  to  that  entry  for  one 
of  the  processors,  while  the  second  flag  would  be  set  to 
allow  the  second  processor  to  access  to  that  entry.  In 
the  case  of  the  Local  Message  Table,  the  X  processor  would 
be  denied  access  to  all  entries  in  the  table,  while  the 
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Y  processor  would  be  allowed  access  to  all  entries  in  the 
table.  Each  operating  system  would  contain  software,  which 
would  poll  each  entry  in  the  table.  The  X  processor  would 
be  searching  for  an  entry  relating  to  a  message  to  a  local 
user.  Its  software  flag  would  be  checked  for  each  entry. 

The  first  entry  which  contains  an  "access"  flag  for  the 
X  processor  would  then  be  fully  processed.  After  the  X 
processor  had  completed  reading  the  data  in  the  entry,  it 
would  then  go  in  and  set  its  software  flag  to  "no  access" 
and  set  the  Y  processor  software  flag  to  "access".  The 
next  time  the  Y  processor  needed  an  entry  location  to  write 
message  parameters,  this  entry  could  be  accessed  by  it. 

When  the  Y  processor  completed  its  data  read,  it  would 
reset  its  own  flag  to  "no  access"  and  then  reset  the  X 
processor  flag  to  "access".  This  mode  of  operation  would 
preclude  simultaneous  accesses  to  the  same  data  byte  and 
insure  data  in  a  given  table  entry  is  not  changed  during 
an  entry  read  operation.  This  concludes  the  discussion 
on  the  software  procedures.  The  next  section  will  deal 
with  several  features  of  the  UNID  implementation. 

Implementation  of  the  UNID 

This  section  deals  with  several  aspects  of  the  imple¬ 
mentation  of  the  UNID  which  were  not  specifically  addressed 
elsewhere  in  this  thesis.  These  features  are  the  genera¬ 
tion  of  the  180°  out-of-phase  clock  signals,  the  addres¬ 
sing  PROM  used  on  the  shared  memory  card,  the  mini-disk 
interface  and  the  wiring  used  in  the  device.  These  features 
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will  be  covered  in  the  order  listed  in  the  following  sub¬ 
sections  . 

Out-of-Phase  Clock  Signal.  For  the  memory  arbitrator 
to  function  correctly,  the  clocks  of  the  two  processors 
must  be  180°  out-of-phase .  The  obvious  way  of  accomplishing 
this  is  to  invert  the  clock  signal  of  one  processor,  and 
provide  it  to  the  second  processor.  This  procedure  was 
accomplished  using  the  X  processor  clock  as  the  source. 

The  Z-80  Microcomputer  Board  (MCB)  provides  an  inverted 
version  of  the  clock  signal  at  pin  99  on  the  board's  edge 
connector.  This  signal  was  wired  to  pin  39  on  the  Y  pro¬ 
cessor  edge  connector  by  means  of  the  backplane  wiring. 

Pin  39  is  a  user  defineable  pin  on  the  Z-80  MCB.  Pins  11 
and  12  on  Integrated  Circuit  A38  (74161:  Synchronous 
Binary  Counter)  were  cut  to  disable  the  Y  processor  clock. 
Then,  a  wire  was  soldered  to  connect  pin  39  to  solder  joint 
A38-12.  This  connection  provided  the  clock  signal  to  the 
Y  processor.  The  cutting  of  the  two  pins  on  the  counter, 
also  removed  the  CLK/2  signal.  This  signal  was  replaced 
by  inverting  the  CLK/2  signal  from  the  X  processor  and 
applying  it  to  the  Y  processor  CLK/2  pin  on  the  mother¬ 
board.  These  changes  in  the  clock  signal  effectively  dis¬ 
able  the  Y  processor  board  when  it  is  not  used  in  the  J2 
slot  of  the  UNID  motherboard.  The  next  subsection  deals 
with  another  modification  to  one  of  the  Z-80  series  boards, 
that  modification  involved  the  replacement  of  an  addressing 
PROM  on  the  RAM  Memory  Board. 
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Addressing  PROM.  This  subsection  deals  with  the 


replacement  of  a  32  x  8  bit  PROM  which  is  used  by  the  Zilog 
RAM  Memory  Board  (Ref  19)  .  This  PROM  is  a  Harris  7603  or 
equivalent,  which  uses  the  four  highest  order  bits  of  the 
address  bus  along  with  the  MREQ  and  RFSH  signals  to  generate 
the  enabling  signals  for  memory  accesses  and  memory  refresh. 
The  PROM  provided  with  the  Memory  Board  placed  the  16K  of 
memory  available  into  the  1st,  2nd,  3rd,  and  8th  pages  of 
the  address  space  of  the  processor.  This  memory  placement 
conflicted  with  the  memory  placement  of  the  RAM  on  the 
Micro-Computer  Boards.  The  4I<  of  RAM  on  each  of  these  boards 
had  to  remain  in  Page  1  due  to  software  constraints  in  the 
system  monitor.  This  conflict  caused  the  addressing  PROM 
to  be  replaced.  No  facility  was  available  to  program  this 
particular  type  of  PROM  so  that,  it  was  decided  to  use 
simple  combinational  logic  to  develop  the  required  signals. 
The  PROM  usually  provides  five  signals  used  by  the  board. 

Four  of  these  signals  are  used  as  bank  select  signals  for 
the  four  banks  of  memory  on  the  card.  The  fifth  signal 
is  used  as  a  second  enabling  signal  for  the  RAM  on  the  card. 
The  16K  of  memory  would  occupy  one  bank  of  memory  on  the 
card  so  that  one  of  the  bank  select  signals,  called  Row 
Address  Strobe  (RASO) ,  and  the  master  RAM  enable  had  to  be 
generated.  The  combinational  logic  used  to  correctly  gen¬ 
erate  the  signal  is  shown  in  Figure  5-2.  The  D5  signal 
corresponds  to  the  RASO  signal  while  the  D4  signal  acts  as 
the  master  RAM  enable.  Table  II  provides  the  truth  table 
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Combinational  Logic  Used  to  Replace  Addressing  PROM 


TABLE  II 


COMBINATIONAL  LOGIC  TRUTH  TABLE 


RFSH 

A15 

A14 

MREQ 

D5 

D4 

X 

X 

X 

H 

H 

H 

L 

X 

X 

L 

I 

H 

H 

H 

L 

L 

■M 

L 

H 

H 

H 

L 

H 

H 

H 

L 

L 

L 

H 

H 

H 

L 

H 

L 

H 

H 

for  the  signals  used.  A  ribbon  cable  with  16-pin  DIP  plugs 
was  used  to  connect  the  off-board  combinational  logic  to 
the  PROM  socket.  The  logic  design  places  the  16K  of  RAM 
into  the  8000„  to  BFFF„  address  space.  This  completes  the 
addressing  PROM  discussion,  the  next  subsection  will  des¬ 
cribe  the  mini-disk  interface. 

Mini-Disk  Interface.  The  prototype  UNID  provides  card 
slot  J5  in  the  motherboard  as  a  point  from  which  to  inter¬ 
face  the  X  processor  with  a  North  Star  Mini-Disk  System. 

At  the  start  of  the  thesis  effort,  this  system  was  intended 
to  support  software  development  activities  on  the  UNID. 

The  interface  is  currently  hardware  compatible,  except  that 
the  initializing  PROM  of  the  Mini-Disk  System  requires 
memory  to  be  available  to  write  the  Disk  Operating  System 


into  Page  2  of  memory.  If  this  PROM  can  be  changed,  the 
system  could  be  used  as  originally  intended.  Documentation 
of  the  Mini-Disk  System  interface  exists  in  reference  8, 
which  is  available  in  the  AFIT  Digital  Engineering  Labora¬ 
tory  Technical  Reference  Files.  The  last  subsection  of 
this  chapter  deals  with  wiring  performed  on  the  UNID. 

UNID  Wiring.  This  subsection  describes  several  aspects 
of  wiring  of  the  UNID.  The  wiring  of  the  device  was  per¬ 
formed  using  30  gauge  wire-wrap  wire,  except  for  a  few 
places,  where  28  gauge  wire  was  used.  The  type  of  signal 
being  used  defined  the  color  of  the  wire  used.  Table  III 
provides  the  color  codes  used.  These  codes  were  used  on 


TABLE  III 

COLOR  CODING  OF  WIRING 


COLOR 

SIGNAL  TYPES 

ORANGE 

Address  Bus 

GREEN 

Data  Bus 

YELLOW 

CPU  Signal  or  inverse 

WHITE 

Logic  generated  signals 

BLUE 

IEI,  IEO,  and  clock  signals 

BROWN 

I/O  to  and  from  Device 

VIOLET 

+12V,  -12V,  Jumpering  for  MCB's 

RED 

+5V 

BLACK 


GND 


all  wires,  except  on  the  signal  lines  from  the  SIO  on  the 
Network  Card  to  its  drivers.  In  this  case  orange  wiring 
was  used  in  leiu  of  brown.  A  wire  listing  for  the  back¬ 
plane  is  included  in  Appendix  D.  This  concludes  the  dis¬ 
cussion  on  the  wiring  of  the  device. 

Summary 

This  chapter  was  intended  primarily  to  review  several 
of  the  peculiar  aspects  in  the  implementation  of  the  UNID. 
The  discussion  is  provided  to  support  any  efforts  on  the 
further  development  of  this  device.  The  sections  in  this 
chapter  should  aid  in  the  understanding  of  the  device,  and 
provide  some  ideas  relating  to  the  direction  of  further 
efforts. 

There  are  certain  specific  areas,  which  should  be 
considered  in  this  regard.  In  the  prototype  version,  Zilog 
Z-80  series  boards  are  used.  The  MCB’s  provide  for  many 
capabilities  (Ref  23) ,  which  would  not  be  necessary  in  a 
production  UNID.  The  RAM  Memory  Board  could  be  integrated 
with  the  Dual  Processor  Card.  Also  once  the  design  was 
fixed  for  the  Local  and  Network  Cards,  it  would  be  desirable 
to  replace  the  wire-wrap  boards  with  printed  circuit  boards. 
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This  chapter  provides  a  brief  description  of  the 
thesis  and  provides  recommendations  relating  to  follow-on 
thesis  efforts,  changes  in  the  device  design,  and  possible 


projects  relating  to  the  device. 

Overview  of  Thesis 

This  report  provides  a  thorough  description  of  the 
hardware  of  the  prototype  Universal  Network  Interface 
Device.  The  nature  of  the  investigation  was  such,  that  the 
greatest  amount  of  effort  was  directed  to  understanding 
and  implementing  previous  efforts.  Therefore,  this  effort 
did  not  result  in  the  development  of  any  significant  con¬ 
tributions  to  the  enhancement  of  man's  knowledge.  However, 
it  is  hoped  that  what  was  accomplished  can  be  readily  un¬ 
derstood  and  further  development  continued  without  much 
delay.  Therefore,  the  chapters  on  the  three  cards  and  the 
UNID  integration  are  provided  to  review  what  was  accom¬ 
plished.  The  next  section  will  address  follow-on  topics 
and  a  specific  plan  relating  to  further  effort  on  the  sys¬ 
tem. 

Follow-On  Efforts 

There  are  two  areas  which  would  provide  topics  for 
follow-on  investigations.  The  first  area  relates  to  the 
software  aspects  of  the  device.  The  software  support 
required  to  support  the  UNID  in  many  different  applications 


is  tremendous.  This  results  from  the  desired  flexibility 
of  the  device  and  the  fact,  that  the  design  requires  that 
the  software  be  the  prime  source  of  the  flexibility. 

There  would  be  two  aspects  to  this  topic.  The  first  would 
be  the  development  of  the  support  software  general  archi¬ 
tecture.  This  would  define  the  methods  for  creating  the 
different  types  of  operating  systems  to  be  used,  to  perform 
major  changes  to  the  software  and  to  perform  minor  changes. 
This  architecture  would  provide  the  software  flexibility 
without  creating  an  unmanageable  software  base.  The  second 
aspect  would  be  a  demonstration  operating  system,  which 
had  changes  incorporated  within  the  constraints  of  the 
above  defined  architecture.  One  area  of  study  would  be  the 
trade  off  between  the  use  of  the  assembly  language  or  a 
higher  order  language. 

A  hardware  investigation  would  involve  extensive 
testing  of  the  device,  implementation  of  Z-80A  processor, 
expansion  of  the  card  cage,  incorporation  of  an  internal 
power  supply,  implementation  of  hardware  modifications 
through  DIP  switches  rather  than  jumpering,  and  construction 
of  a  chassis  to  support  the  device  and  its  interfaces. 

These  aspects  will  be  discussed  briefly  in  the  paragraphs 
below. 

The  testing  of  the  device  to  date  was  aimed  at  the 
Dual  Processor  Card  with  the  two  other  cards  receiving  little 
attention.  At  the  present  time,  the  Dual  Processor  Card 
does  not  provide  perfect  arbitration  of  the  memory  accesses. 
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Testing  on  the  Card  shows  that  there  are  times  that  data 
bytes  are  incorrectly  written  to  the  stored  memory,  when 
the  other  processor  is  making  memory  accesses.  Therefore 
testing  should  be  performed  relating  to  the  timing  of  the 
write  signal  to  isolate  the  source  of  this  problem.  It 
was  found  that  the  detailed  drawings  and  a  logic  analyzer 
were  indispensible  during  testing  of  the  device.  Minor 
testing  was  performed  on  the  Local  Card  and  the  Network 
Card.  The  address  decoding  logic  and  data  bus  controlling 
logic  tested  correctly  for  both  cards.  The  CTC's  on  both 
cards  were  successfully  tested.  However,  further  testing 
is  required  to  insure  that  interrupts  are  handled  correctly 
and  the  conununcations  devices  can  be  programmed.  It  is 
recommended  that  these  testing  activities  be  confined  to 
the  various  parts  of  each  board  so  as  to  verify  the  cor¬ 
rect  operation  of  all  parts  of  each  card,  before  testing 
each  card  as  a  unit. 

Implementation  of  Z-80A  processors  is  a  requirement 
for  the  device  to  meet  its  original  design  configuration. 
This  implementation  could  well  cause  problems  in  the  arbi¬ 
tration  of  memory  accesses,  plus  causing  the  replacement 
of  the  microcomputer  boards  and  the  RAM  Memory  Boards. 

The  last  four  tasks  would  not  be  difficult  but  they 
could  be  time  consuming.  The  DIP  switches  would  deal  with 
at  least  six  I/O  channels  for  a  basic  device,  plus  two 
I/O  port  address  areas  and  the  interrupt  addresses  on  the 
Local  Card.  A  new  card  cage  is  required  to  support  any 
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configuration  more  complex  than  the  basic  device.  The 
device  chassis  would  be  challenging  in  trying  to  get  an 
arrangement  that  would  allow  for  testing  and  modification, 
yet  minimizing  size.  The  culmination  of  these  six  tasks 
would  be  a  device  in  a  pre-production  configuration. 

Changes  in  Device  Design 

The  first  change  recommended  is  that  the  shared  memory 
be  replaced  with  static  RAM.  The  current  use  of  dynamic 
RAM  triples  the  complexity  of  the  Dual  Processor  Card. 

And  it  would  be  possible  to  lose  data  in  memory  if  enough 
of  the  appropriate  refresh  signals  are  inhibited.  These 
reasons  suggest  that  Static  RAM  be  used  as  the  shared 
memory  component.  The  second  recommendation  deals  with  the 
Network  Card.  The  design  goal  data  rate  is  1.5  Megabit/ 
sec.  The  Z80A-SIO  can  function  at  880  Kilobits/sec  in  half 
duplex  mode.  Achievement  of  the  desired  data  rate  might 
be  possible  with  a  Signetic  2652  Multi-Protocol  Communica¬ 
tions  Controller  (MPCC) .  The  MPCC  data  rate  specification 
is  2  Megabit/sec  and  it  includes  all  features  of  the  Z80- 
SIO.  It  can  also  interface  with  an  8-bit  or  16-bit  data 
bus.  Thus,  it  would  be  upward  compatible  with  a  16-bit 
processor  if  such  a  requirement  became  necessary.  The 
last  change  recommended  was  stated  in  the  previous  section. 
That  change  is  that  the  UNID  processors  be  upgraded  to 
Z-80A' s . 
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Recommended  Projects 

These  project  recommendations  propose  lower-level 
efforts  as  possible  lab  projects  for  a  microprocessor 
interfacing  laboratory.  The  first  proposal  is  that  the 
UNID  be  interfaced  with  a  separate  Zilog  microcomputer 
system  which  is  available  in  the  Digital  Engineering  Labora¬ 
tory.  The  second  proposal  is  that  a  lab  group  perform  some 
of  the  testing  activities  which  were  recommended  previously. 
The  scope  of  this  effort  could  be  easily  modified  by  re¬ 
quiring  the  testing  of  a  particular  combination  of  the 
three  cards.  Accomplishment  of  either  of  these  projects 
would  take  the  implementation  of  the  UNID  one  step  closer 
to  a  pre-production  version  of  a  flexible  message  proces¬ 
sor  which  could  be  used  in  different  types  of  computer 
communications  network  applications. 
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